iT邦幫忙

2026 iThome 鐵人賽

DAY 7
0
Kubernetes

不是背 YAML!30 天從零打造 Kubernetes 微服務:從本機實戰一路到 CKA系列 第 7

Day 7|Deployment 與 ReplicaSet:第一次看到 Kubernetes 的 Self-Healing

  • 分享至 

  • xImage
  •  

還記得 Day 5 時,我們做了一件事:

kubectl delete pod nginx

一個 delete,就讓 Pod 就真的消失啦

但 Production 系統不能這樣搞啊。

如果凌晨三點 API Crash:

不可能等工程師醒來再手動執行 kubectl run。

所以我們需要 Controller (可以想成幫忙自動控制的)。

現在最常用的就是透過:

Deployment。

https://ithelp.ithome.com.tw/upload/images/20260907/20168537sqhimL6UjX.png


建立 Deployment

kubectl create deployment api \
  --image=nginx:alpine \
  --replicas=3 \
  -n cka-lab

查看:

kubectl get deployments -n cka-lab

縮寫:

kubectl get deploy -n cka-lab

接著:

kubectl get pods -n cka-lab

你會看到三個:
https://ithelp.ithome.com.tw/upload/images/20260907/20168537DTWuK2Ax0l.png


觀念釐清:Deployment 並沒有直接管理 Pod

這是非常重要的關係:

Deployment
    │
    ▼
ReplicaSet
    │
    ▼
Pod

看看:

kubectl get rs -n cka-lab

https://ithelp.ithome.com.tw/upload/images/20260907/2016853715vL5QzTYN.png

你會看到一個 ReplicaSet。

Deployment 管理 ReplicaSet。

ReplicaSet 再確保指定數量的 Pod 存在。


現在故意殺一個 Pod

先:

kubectl get pods -n cka-lab

任選一個:

kubectl delete pod <API_POD_NAME> -n cka-lab

https://ithelp.ithome.com.tw/upload/images/20260907/20168537v0alPrfgq7.png

立刻:

kubectl get pods -n cka-lab

會發現:

舊 Pod Terminating
新 Pod Creating

這跟 Day 5 完全不一樣。

因為 ReplicaSet 發現:

Desired = 3
Actual = 2

於是:

補一個。

這就是:

Self-healing

最直觀的體驗。


Scale

現在:

kubectl scale deployment/api \
  --replicas=5 \
  -n cka-lab

看看:

kubectl get pods -n cka-lab

https://ithelp.ithome.com.tw/upload/images/20260907/20168537m65ebg0Z2l.png

變五個。

再:

kubectl scale deployment/api \
  --replicas=2 \
  -n cka-lab

變兩個。

https://ithelp.ithome.com.tw/upload/images/20260907/201685372qAS5XPc5w.png

我們不是:

手動 create Pod
手動 delete Pod

而是在修改:

Desired State。

Deployment YAML

把它轉成宣告式:

apiVersion: apps/v1

kind: Deployment

metadata:
  name: api
  namespace: cka-lab

spec:
  replicas: 3

  selector:
    matchLabels:
      app: api

  template:
    metadata:
      labels:
        app: api

    spec:
      containers:
        - name: nginx
          image: nginx:alpine

這裡第一次看到:

selector:
  matchLabels:
    app: api

Deployment 在說:

哪些 Pod 是我的?

接著:

template:
  metadata:
    labels:
      app: api

新建立的 Pod 都貼:

app=api 的標籤

兩邊吻合。


template 是什麼?

Deployment 不直接描述:

一個現有 Pod。

它描述的是:

Pod Template。

也就是:

未來你要建立 Pod 時,都照這個模板。

因此:

Deployment
↓
ReplicaSet
↓
從 Template 建 Pod

kubectl delete pod 為什麼不算真正修復?

有時候大家遇到問題會:

kubectl delete pod

發現新的 Pod 正常,就說:

修好了。

其實不一定。

如果根本問題在:

Deployment Template

新 Pod 還是會使用相同設定。

因此真正排錯要區分:

這一個 Pod 偶發壞掉?

還是 Desired State 本身就錯?

這是 Debug 中很重要的思維。


Day 7 小結

今天第一次真正看到 Kubernetes 的核心能力:

Desired State
↓
Controller
↓
Self-Healing

也理解:

Deployment
↓
ReplicaSet
↓
Pod

明天我們要開始做真正 Deployment 最重要的事情:

更新 Application。

而且看看 Kubernetes 怎麼做到不一次把所有服務停掉。


上一篇
Day 6|Label、Selector、Namespace:Kubernetes 是怎麼找到「自己人」的?
下一篇
Day 8|Rolling Update 與 Rollback:Kubernetes 怎麼做到不中斷更新?
系列文
不是背 YAML!30 天從零打造 Kubernetes 微服務:從本機實戰一路到 CKA10
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言